RSA-konferensen i San Francisco öppnade idag med seminariespår och inledande föreläsningar. Ett av spåren arrangerades av Cloud Security Alliance (https://cloudsecurityalliance.org) och lade stort fokus på olika ideér som bl.a. berörde:
Som svar på de flesta frågor ovan hamnade mycket av diskussionerna i det som går under begreppet Cloud Access Security Broker (CASB). En CASB kan kort sammanfattas som en proxy mellan en eller flera organisationer och en eller flera molntjänster som nyttjas av anslutna organisationer och där man kan kontrollera, styra och följa upp användning av molntjänster på ett centralt sätt. Till en CASB kan man därefter koppla annan infrastruktur som t.ex. loggtjänster eller autentiseringstjänster för att kunna dra nytta av ny eller befintlig infrastuktur för att exempelvis få spårbarhetseffekter på organisationens användning av berörda molntjänster.
Även om vi på Certezza tycker att denna typ av tjänster är intressanta i olika sammanhang är det inte utan att branschen fått ännu ett buzzword att förhålla sig till och när diskussionen alltför ofta mynnar ut i sådant som torde vara självklarheter i en organisations arbete med informationssäkerhet, exempelvis att man FÖRST värdera och klassificerar information i relation till skyddsvärde, risker och hotbild för att DÄREFTER tillämpa lämpliga skyddsåtgärder kopplat till just värde, risker och hot. Tillämpningen kan t.ex. resultera i att man ställer krav på tjänsteleverantörerna eller helt enkel beslutar att inte flytta ut just det datat i molnet. Återigen finns aktörer i tillverkarledet som ännu en gång försöker övertyga att tekniska lösningar och infrastruktur är det som ska lösa alla utmaningar som dyker upp vid användning av molntjänster. Det inte utan att man står där med lite skeptiskt ansiktsuttryck.
Vi frågar oss dessutom än en gång, varför ska det vara någon skillnad på den egentliga kravbilden om man använder sig av en molntjänst eller väljer att drifta en egen lokal tjänst för något specifikt ändamål? I en sund verklighet så förändras ju inte skyddsvärdet på den faktiska informationen bara för att man väljer en driftmodell framför en annan. Däremot kan ju självklart risker och hotbild påverkas av att man väljer/inte väljer att drifta en tjänst hos en molntjänstleverantör.
En annan fråga som vi tycker bör belysas när det gäller molntjänster är att molntjänster av typen SaaS (Software As A Service) och PaaS (Platform As A Service) anropas på helt andra sätt än traditionell outsourcing av infrastruktur. SaaS och PaaS används till stor utsträckning genom API-anrop mot tjänsten ifråga, dvs. det finns en konsumentdel hos den nyttjande organisationen (tänk klient) och en producentdel hos molntjänstleverantören som exponerar ett antal API:er som gränssnitt mot tjänsten ifråga. Likaså IaaS (Infrastructure as a Service) kan administreras genom API:er. Just kvaliteten på dessa API:er är mycket avgörande när man utvärderar skyddsnivån på denna typ av molntjänster. Vi på Certezza tycker det är viktigt att man har med sig detta som en typisk ny risk som måste hanteras, när man kravställer gentemot molnleverantörerna. Merparten av de traditionella infrastrukturnära skyddsmekanismerna som används som säljargument av molntjänstleverantörer skyddar inte en tjänst med trasiga API:er. Annars blir det lätt som att glömma bort att en båt faktiskt ska kunna flyta på vatten eller att en bil ska runda hjul för att kunna rulla både framåt och bakåt.
En annan liten notis vi vill nämna från dagen är att det nu även startats upp ett arbete med att specificera och standardisera ett antal API:er som är tänkta att kunna användas för att styra säkerhetsrelaterad konfiguration av molntjänster på ett enhetligt sätt oberoende av enskilda leverantörer. Som vanligt återstår det väl att se hur väl detta på sikt skulle kunna tillämpas av olika typer av molntjänstleverantörer, utan stöd på leverantörssidan kommer det ju tyvärr bli en ganska tråkig standarduppsättning API:er och med tanke på att arbetet är alldeles nystartat är det för tidigt att uttala sig om hur väl detta kommer att utvecklas. Tanken på att kunna ta fram och använda enhetliga konfigurationsverktyg mot olika molntjänst leverantörer är dock mycket kittlande. Alla organisationer som dragit erfarenheter som hur komplext det lätt blir att tillämpa rätt konfiguration över olika leverantörer torde vittna om hur denna komplexitet snarare är exponentiell än linjär.
Vad är då summeringen av allt detta? Vi på Certezza fortsätter med en dåres envishet att hävda att det inte är valet av enskilda tekniska lösningar som är avgörande för vilken skyddsnivå man faktiskt uppnår. I en optimal verklighet utgår man från informationssäkerhetsperspektivet och väljer därefter skyddsåtgärder utifrån skyddsvärde, risker och hotbild. Det är med andra ord inte en metod som är unik för molntjänsters vara eller icke vara. Som två Certezzianer på ett hotellrum i San Francisco säger till varandra med värme i rösten ”enskilda tekniska lösningar kommer och går medans sunt tänk består”.
Conny Balazs och Carl Önne
